Introduction to the Collaborative Information suite 3
Overview of the Collaborative Information suite 3
Typical client applications for the Collaborative Information suite 4
Important Information About The CI Suite 4
Using object specifiers in place of other parameters 11
Usage scenarios 12
Getting cEntity Information 12
Getting a cAddress from a cEntity 13
Getting different subclasses of cAddress from a cEntity 13
Apple events defined in the Collaborative Information suite 14
Object classes defined in the Collaborative Information suite 15
Table 2 Apple event object classes defined in the Collaborative Information suite 15
i.cCatalogNode 24
i.cCIRecord 27
i.cAttribute 30
i.cUserField 33
cPhoneNumber 35
i.cAddress 38
cMailAddress 40
i.cPostalAddress 43
i.cFAXAddress 46
i.cPhoneAddress 48
i.cBeeperAddress 50
i.cEntity 53
i.cPerson 57
i.cEquipment 62
i.cLocation 66
i.cOrganization 70
Descriptor types defined in the Collaborative Information suite 74
Table 4 Descriptor types defined in the Collaborative Information suite 74
typePhoneNumber 75
i.typeAttribute 78
i.typeAddress 79
i.typePostalAddress 80
i.typePhoneAddress 81
typeMailAddress 81
i.typeEntity 84
i.typePerson 85
i.typeEquipment 86
i.typeLocation 87
Constants defined in the Collaborative Information suite 87
Table 7 Constants defined in the Collaborative Information suite 87
Introduction to the Collaborative Information suite
The Collaborative Information suite defines Apple event constructs for applications which deal with contacts, resources, locations, and addresses. It builds on the Table and Data Base suites, so familiarity with these suites is recommended. The Collaborative Information suite can be used alone for retrieving information about entities, or it can be used in conjunction with other suites (such as ones which define constructs for time, events, projects, etc.) to perform complex functions relating entities with other types of information.
This suite is also designed so that it can be used in conjunction with the Telephony and Mail Suites to support the integration of various applications in personal communications, workflow and other collaborative solutions.
Overview of the Collaborative Information suite
The Collaborative Information suite defines object classes for
n records, which contain information for anything which has information to support collaboration.
n attributes, which contain the individual pieces of information found in a record.
n entities, which are records that contain information for any person, place, or thing which has a primary address and can have its time or other information managed.
n addresses, which are pieces of information describing various types and kinds of means for communicating with or reaching an entity.
The Collaborative Information suite also defines AppleEvent protocols for
n identifying the structure of a particular CI server
n finding entities and records
n getting various addresses and attributes of entities and records
The Collaborative Information suite also suggests general guidelines for
n Address Coercions.
n Entity IDs.
Applications that should implement the Collaborative Information suite
The following types of applications should support the Collaborative Information suite:
n applications that directly access AOCE catalog services
n applications that manage contact information
n applications that manage resource information (equipment, locations, etc)
Typical client applications for the Collaborative Information suite
The following types of applications are likely to be clients of applications that support the Collaborative Information suite:
n calendar and scheduling applications which want to link to a contact manager
n word processors which want to automate mail merging and simplify address retrieval
n spreadsheets, databases, and other information managers which don’t want to duplicate information in a contact manager
n project managers which want to provide access to contact and resource information
Important Information About The CI Suite
Intro
The CI suite defines two basic kinds of objects and several sublcasses. It also outlines several guiding principles for CI servers and clients, which if followed by all client and server applications will foster a new level of communication and functionality for the end user.
Entities
Entities are the primary object type for the Collaborative Information Suite. An entity is defined as any "thing" which can be located in any number of space coordinates, be it physical, electronic, or otherwise. Each entity can have any number of pieces of information (as address or user field elements), but must have at least the basic information defined for a cEntity object. For example, a cPerson is a subclass of cEntity, and may have name information, several different user fields, and several different addresses. Notice that by abstracting many properties of cPerson into cEntity, the suite can also define other items such as cLocation and cEquipment. Then any list of cEntity objects can be iterated without regard for the type of each object. For example, a calendar program could iterate through a list of entities which contain three people, a meeting room and a slide projector, to find the next free time and then schedule a meeting.
Attributes, Addresses, and user fields
Atributes are containers for bits of information in records. Any kind of information can be stored in attributes; in this manner, the object cAttribute is similar to, but not descendant from, cCell. The CI Suite defines two special kinds of information that can be found in attribute objects: addresses and user fields. This allows data access at two levels. On a low level, all the bits of information can be accessed without distinction via cAttribute objects. On a high level, via cAddress and cUserField objects, bits of information can be retreived as recognizable collections using familiar terms.
There are several kinds of address types defined in the suite. Any address can be retrieved either in a text format or in a descriptor record; the default type for all addresses is typeIntlText. An address can also be accessed via its properties, depending on the clients needs. For example, a word processor could retrieve the first postal address for an entity as text, or could just retrieve the zip code property of the first postal address. Basic address types have been defined for postal addresses, phone numbers, and electronic mail accounts. Other address types can easily be defined, allowing for extendibility.
Addresses are also classified in one of two ways: realtime or store-and-forward. Realtime addresses are addresses in which a connection is made between sender and recipient, and information is exchanged synchronously. For example, phone numbers are realtime addresses. Store-and-forward addresses are addresses in which information is delivered over a period of time from the sender to the recipient asynchronously, and no realtime connection is made. Postal addresses are a classic example of store-and-forward address types.
Because a cEntity object is defined by its property of location, each cEntity object has both a pPrimaryMailAddress and pPrimaryRealTimeAddress property, each containing some appropriate subclass of cAddress. If a client application asks for "the primary address" of a cEntity, the server should return the pPrimaryMailAddress. The server is responsible for defining what the pPrimaryMailAddress for each cEntity is, either by itself or thru user preference. If a client application asks for "the primary realtime address" of an cEntity, the server should return the pPrimaryRealTimeAddress. Again, the server is responsible for defining what the pPrimaryRealTimeAddress for each cEntity is.
Each cEntity, usually has more than one or two addresses, and sometimes has more than one for each type, such has a person having one postal address and several phone numbers. Addresses can be retrieved either by formAbsolutionPosition or by name. When retrieved by formAbsolutePosition, it is up to the CI Server to determine the order of the addresses within an entity.
To illustrate, lets define a scenario where a client application is polling a server for various addresses of a given cPerson, which has one cPostalAddress as the pPrimaryMailAddress, and three cPhoneNumber addresses, the second of which is also the pPrimaryRealTimeAddress. If the client application asks for "the primary address" of the cPerson, then the pPrimaryAddress is returned. If the client applications asks for "the primary realtime address" of the cPerson, then the second cPhoneNumber is returned. If the client application asks for "the first phone number", then normal formAbsolutePosition is used to return the first cPhoneNumber defined. Notice that the indexing of addresses changes depending on which type of address is being asked for ("second address" indexes thru all addresses whereas "second phone number" indexes thru only the phone number addresses).
Open Ended Structure
Because collaborative applications vary widely as to what information is stored with each entity, records must have a variable number of elements and be designed with an extensible framework in mind. For this reason, the Collaborative Information Suite is designed on top of the Table suite. This allows a cEntity object to be used analogous to a cRow, and the cEntity's elements as cCells of a cRow. cAddress and cUserField, then, are subclasses of cCell. A developer may wish to implement the CI suite on top of the Database suite; this will have no averse effect on the definition of the CI Suite. Each application which implements the Collaborative Information suite is responsible for mapping their internal structures into various address type and user fields, where appropriate.
Since each CI server can implement the CI Suite to suit their needs, client apps to CI servers are responsible for getting the structure of the table from which it wants to get entity information, IF it wants to access specific elements defined by the server by either formAbsolutePosition or formName. If a client app simply wants to access primary address or preferred information about a cEntity, little knowledge of the server applications structure is required.
Entity IDs
The ID property of an entity plays a very important role for the CI suite. These IDs can be used for data relationships within other application, and in reconciliation between two sets of equivalent data by applications of a similar nature.
One of the scenarios envisioned for this suite is a data link between a CI server and a client application. For example, a project planning application may keep a list of personnel for each project within its data structure. The project application could access a CI server to get information about the people involved with the project, and store the IDs of each person within its own data. Later, if the project application needs to re-access that information, it can use the IDs it has stored to access the information in the CI server quickly using the formUniqueID keyform.
A specialized case of data links might be between two CI servers, one in a desktop machine and another on a portable device. A user could direct the desktop machine to download a bunch of contact information into the portable device via AppleEvents, and then take the portable device out of the office. Later, when she returns to the office, she could reconcile the data in her portable device with the data on the desktop using the IDs. Each application can store the information in whatever format it requires; as long as the IDs are preserved, reconciliations can occur. (A Reconciliation AppleEvents Suite to facilitate reconciliation would be most excellent!)
With these scenarios in mind, implementors of the CI suite need to be aware of two important aspects of IDs: its size and its struture. In this version of the CI suite, neither the size nor the internal structure of an entity ID is defined. It is left to the implementor to devise a scheme that generates IDs. IDs should be large enough to provide a sharp resolution such that the likelihood of two copies of any program generating the same ID is very small. IDs should also be as compact as possible so that client applications using those IDs can store them within their own data structures without taking up too much space.
[[[We can make some recommendations that will help foster the scenarios discussed above, and new levels of functionality in the near future. Collaborative Information Suite servers should define IDs in size between 10 and 20 bytes. IDs under 10 bytes in size do not provide a high enough resolution to guard against duplicity, and IDs larger than 20 bytes may force too much burden on client applications which want to store ID information. Client applications to the CI suite should design their structures to handle variable size IDs if they want to store them. CI Servers may also want to implement a variable size ID so that it can handle and store entity records with foriegn ID schemes received from other CI Servers.]]]
Entity Names
Entity names are used as the primary method of retreiving entity information in any form of scripting (or end user) environment. Since entity IDs are application defined, a script user or a client application should not know the internal structure of an ID, and therefore should not attempt to generate one explicitly (It is acceptable to internally use ID returned by a CI suite server, such as when a list of entity IDs is returned and subsequently iterated). The pName property of each cEntity is defined by the implementing application, and cannot be modified by a client application. The pName field may be defined by the combination of other fields, such as the pFirstName and pLastName propertiers of a cPerson. In this case, if a client changes either of these latter properties, the pName property would also change.
Finding Entities
In almost all cases, an end-user will want to find an entity by name and retreive some address from it. In the case where the name is unique within the datafile, the server should return the information requested. If, however, there are several entities with the given name, an error is returned by the CI Server (errAEMoreThanOneFound?). At this point the client application may wish to count the number of entities with that name, retrieve the entities, and display them in a list for the user to choose from.
Accessing information via cEntity or cRecord versus cRow
The CI Suite defines itself on top of the Table and Data Base Suites. BUT, the number of addresses and attributes is not a fixed number for each entity, as is the case with the number of cells in each row. This is due to the fact that addresses and user fields for an entity may not be stored in the table itself, and may be retrieved by the CI Server transparently. One thing to remember, then, is that there could potentially be several ways to access information. Because address information may be a combination of columns within a table, and because the number of addresses and user fields may vary from entity to entity, the number of cells in a row may not be equal to the number of address plus the number of user fields in an entity. Client applications should always count the number of addresses and user fields of an entity, and count the number of columns in a table.
Of course, a CI Server need not implement any of the table or Data Base suites, but rather just implement the CI Suite, and so would not need to worry about this at all.
Containment Hierarchy
The CI Suite provides many different ways of getting to various pieces of information through a multitude of object types. However, many of these object types are simply specializations of one another. The containment hierarchy for the CI suite is therefore very straightforward and is illustrated in Figure 1. The cCatalog Node objects are subclasses of Tables so that table and data base events may be applied. Even more significantly, the catalog objects are recursive so that one can nest any number of catalogs inside one another.
CI Suite and AOCE
Much of this structure and framework is similar to AOCE catalog services; this is no coincidence. The CI suite makes all of the information in an AOCE catalog available through the cCatalogNode, cRecord and cAttribute types. It also makes it easy to get access to AOCE addresses and phone numbers through the other CI Suite objects.
Using object specifiers in place of other parameters
In all of the suites except the Finder suite (and even then this is changing soon), you can substitute an object specifier for any parameter of an Apple event that is not already defined to be an object specifier. This object specifier must specify a single object. When you substitute an object specifier for another parameter, the actual value of the parameter is the value of the default descriptor record for the specified object (that is, the value you get when you send a Get Data Apple event for the object and do not specify a particular descriptor type for the result).
Usage scenarios
The Collaborative Information suite will allow the user to accomplish things that
are not easy to do with other suites. This is possible primarily because the
suite is structured around the concept of entities and addresses. Hence, the
typical usage scenarios take advantage of this structure to get or set the
address of a specific entity.
Basic example I: The name of a person appears in an project management document.
That application can use this suite to get the phone number of the person from
a contact manager, and then use it for automatic data entry, dialing, or
arbitrary other purpose.
Basic example II: a user types the name of a person at the top of a new word processor document and then selects a menu item to look up the address. The word processor takes the name and sends an event to a contact manager to get the address, then inserts the address below the name in the document.
Impressive example: A word processor could loop through a list of names, get a
full address from a contact manager, and insert the address into a letter for
an efficient mail merge.
Top Gun example: A magazine editor could type some buzzwords for a story into
an outliner. A contact manager could use these to search through a "notes"
column and return a list of all the people that match the buzzwords,
creating a source list that can be sent to a reporter (who can then use the
basic example I to access a phone number or address).
Of course, there is plenty of room for the enterprising developer to use the
suite in ways that extend beyond those listed here.
Getting cEntity Information
Applications can get a cEntity record by sending a simple GetData event. For scripting languages, the nouns "person", "location", and "equipment" can all be substituted with "entity", but not the vice versa. For example:
The following pseudo-script returns a AERecord of type typePerson, which contains many of the properties of cPerson and all the addresses and user fields of that person in their best types (usually typeAddress and typeUserField).
tell application "MyContactsApp"
set x to person "Kawa@"
end tell
The following pseudo-script returns a AERecord of type typeOrganization. Notice that because the script asks for an organization instead of a person, the CI Server may elect to return "Kawasaki Inc" instead of "Guy Kawasaki".
tell application "MyContactsApp"
set x to organization "Kawa@"
end tell
(the @ symbol is often used to perform a "begins with" search. It is used here for illustration purposes and is not define in this suite.)
Getting a cAddress from a cEntity
Applications can get an address of a cEntity record by sending a simple GetData event. For scripting languages, the nouns "person", "location", and "equipment" can all be substituted with "entity", but not the vice versa. To get an address, simply specify the container:
The following pseudo-script returns a a string containing the first address for the entity.
tell application "MyContactsApp"
set x to address 1 of person "Jim Kaslik"
end tell
The following pseudo-script returns a a string containing the named address for the entity.
tell application "MyContactsApp"
set x to address "Applelink" of person "Danny Cooley"
end tell
Getting different subclasses of cAddress from a cEntity
Applications can get an address of a cEntity record by sending a simple GetData event. For scripting languages, the nouns "person", "location", and "equipment" can all be substituted with "entity", but not the vice versa. To get an address, simply specify the container, and either a name or an index.
This pseudo-script returns a a string containing the second phone number.
tell application "MyContactsApp"
set x to phone number 2 of person "Dave Evans"
end tell
This pseudo-script returns a a string containing the mail address with the given name.
tell application "MyContactsApp"
set x to mail address "Applelink" of person "Michael Bayer"
end tell
Apple events defined in the Collaborative Information suite
There are no new events defined by the CI suite.
Object classes defined in the Collaborative Information suite
The Apple event object classes defined in the Collaborative Information suite are described in the following sections. Table 2 lists these object classes.
n Table 2 Apple event object classes defined in the Collaborative Information suite
Object class ID Description
cCatalogNode A hierarchial container for information
Element Classes: cAddress, cUserField, cCell, cAttribute, cEntity, cPerson, cLocation, cOrganization
Figure 2 illustrates the inheritance hierarchy for the object classes defined in the Collaborative Information suite Level 1. Figure 3 illustrates the inheritance hierarchy for the object classes defined in the Collaborative Information suite Level 2. Level 1 support provides high level access to contact information, grouping information into functional collections. Level 2 support provides lower level access to raw data. Listed for each object class are the properties, element classes, and Apple events that have not been inherited from object classes higher in the inheritance hierarchy.
[intentionally blank]
[intentionally blank]
[intentionally blank]
cCatalogNode—a node
SuperClass cTable
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pName
Description: the name (type) of this catalog node.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pProtection
Description: The …
Object Class ID: cType
Inherited? Yes, from cTable
Modifiable or
Non-modifiable? Non-modifiable
pAccess
Description: the access priviliges for this attribute. This can be Read-Only, Read-Update, Read-Create, Read-Delete, Read-Update-Create, Read-Update-Delete, Read-Create-Delete and Read-Write. (???)
Object Class ID: cEnumeration
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pKind
Description: The kind of catalog node
Object Class ID: cType
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pLock
Description: The current lock state of this catalog node
Object Class ID: cType
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Modifiable
pID
Description: the unique ID for this catalog node
Object Class ID: cLongInteger
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pPath
Description: The path to this catalog node from the root
Object Class ID: cList
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
Element Classes
cCatalogNode
Description: a child catalog node of this catalog node
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAccess
Description: the access priviliges for this attribute. This can be Read-Only, Read-Update, Read-Create, Read-Delete, Read-Update-Create, Read-Update-Delete, Read-Create-Delete and Read-Write.
Object Class ID: cEnumeration
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pLock
Description: The current lock state of this catalog node
Object Class ID: cType
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Modifiable
pName
Description: the name of this record. For example, "Danny Cooley", "Tech.LaserWriter", "Marketing NetModem", etc.
Object Class ID: cIntlText
Inherited? yes, from cRow
Modifiable or
Non-modifiable? Modifiable
pUniqueID
Description: the unique ID for this record
Object Class ID: cText
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Non-modifiable
Element Classes
cAttribute
Description: an attribute conatined within this record
An attribute is a container piece of information related to any entity or other record. A CI Server can define an attribute to hold any kind of information, not just text. All of the addresses for a given entity are available in attributes in addition to non-address information. The pValue of the cAttribute contains the actual data. By checking the type of the attribute using the pName and pTag properties, a client can coerce the data appropriately and retrieve it in a useful structure. Attributes offer an alternative approach to accessing information in the CI suite. Address information related to a particular cEntity (which is a subclass of cCIRecord) can be obtained directly through cAddress class objects. The CI Server is free to define any attributes for a given record regardless of whether they actually exist as attributes or fields in the corresponding catalog or directory. Clients can also access information related to a given record through its cCells. cCells for a given record do not however neccessarily map to cAttriutes or vice versa.
SuperClass cObject
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAccess
Description: the access priviliges for this attribute. This can be Read-Only, Read-Update, Read-Create, Read-Delete, Read-Update-Create, Read-Update-Delete, Read-Create-Delete and Read-Write.
Object Class ID: cEnumeration
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pID
Description: the unique ID for this attribute
Object Class ID: cLongInteger
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pName
Description: the name (type) of this attribute. For example, "Mail Address", "Phone Number", "Signing Authority", etc.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pTag
Description: more information on the type of data contained in the attribute. The interpretation of the Tag is based on the pName. For example, if pName is "Mail Address" then pTag could be 'fax ', 'smtp', 'post', 'ALNK', etc.
Object Class ID: cType
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pValue
Description: the actual data of the attribute
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cUserField—any piece of non-address information
A user field is a convenient class for information not related to address information. When a CI server determines how to classify information for client requests, and the client is asking for address and non-address information, all non-address information should be considered user field information.
SuperClass cObject
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pName
Description: the name of this user field. For example, "Category", "Keyword", "Salary", etc.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pValue
Description: the actual data of the user field
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cPhoneNumber—a representation of a telephone number
The cPhoneNumber object class is the class for representation of a telephone number in a telephone network. This is the same definition found in the Telephony Æ Suite.
Superclass cObject (Core suite)
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pCountryCode
Description: The country code for the phone number
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pDialPlanRules
Description: A descriptor list containing typeIntlText descriptor records. The items in the list specify the dial plan rules for the phone number
Object Class ID: cList
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pExtension
Description: The extension for the phone number. The extension must be empty if the subscriber number and subaddress fully specify the phone number.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pSubaddress
Description: The subaddress for the phone number
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pSubscriberNumber
Description: The core for the phone number
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pTrunkCode
Description: The area code for the phone number
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cAddress—an abstract address class
The cAddress object class is the class for generically representing all types of addresses for entities, and as such should never really exist.
SuperClass cObject
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of addressee
Object Class ID: cType
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cMailAddress—a representation of an address
The cMailAddress object class is the class for the representation of a destination for a electronic letter. In addition to the information necessary for the appropriate mail transport to deliver the letter, cMailAddress includes the name, and if appropriate, the type of destination being mailed to. Note that the cMailAddress here is identical to the one found in the Mail suite except that no pName is supported in the Mail suite. Also, note that any subclass of cMailAddress can be coersed and returned as a cMailAddress object, in addition to any other coersion types available.
Superclass cObject
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of the addressee. For Mail, this is normally 'User'.
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddress
Description: The actual address of the type specified by pAddressType in the address space specified by pDirectory.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pDirectory
Description: The name of the address space or the subaddress space specified as a path within the address space for direct addressing or the directory or directory node path for indirect addressing.
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pDirectoryType
Description: The type of the address space or directory.
Object Class ID: cType
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pDirectoryID
Description: The unique ID of the address space or directory.
Object Class ID: cLongInteger
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Clone Inherited from cObject
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Move Inherited from cObject
Set Data Inherited from cObject
cPostalAddress—a postal address used by couriers
This is a postal address. It is an alternate representation of a cMailAddress whose pAddressType is 'post'.
SuperClass cMailAddress
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of addressee
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pRoomNumber
Description: the room number, suite, apartment number, etc
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pBuildingNumber
Description: the building number
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pStreet
Description: the street name
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pCity
Description: the city name
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pStateProvince
Description: the state or province
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pCountry
Description: the country
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pPostalCode
Description: the zip code or equivalent
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cFAXAddress—a FAX address
This is a telephone number designated to receive FAX transmissions.
SuperClass cMailAddress
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of addressee
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pPhoneNumber
Description: the actual FAX telephone number
Object Class ID: cPhoneNumber
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cPhoneAddress—a telephone address
This is a phone number designated for voice communication.
SuperClass cMailAddress
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of addressee
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pPhoneNumber
Description: the actual phone number
Object Class ID: cPhoneNumber
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cBeeperAddress—a beeper address
This is a phone number designated to receive simple commands and page a wireless beeper.
SuperClass cPhoneAddress
Default Descriptor
Type
typeIntlText
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeName
Description: The name of the addressee
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddresseeType
Description: The type of addressee
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressType
Description: The type of the address
Object Class ID: cType
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pAddressName
Description: The name of the address
Object Class ID: cIntlText
Inherited? Yes, from cAddress
Modifiable or
Non-modifiable? Non-modifiable
pPhoneNumber
Description: the actual beeper telephone number
Object Class ID: cPhoneNumber
Inherited? Yes, from cPhoneAddress
Modifiable or
Non-modifiable? Modifiable
pPINNumber
Description: the PIN number that identifies the beeper subscriber
Object Class ID: cIntlText
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes None
Apple Events
Apple events from the Core suite:
Count Elements Inherited from cObject
Create Element Inherited from cObject
Delete Inherited from cObject
Do Objects Exist Inherited from cObject
Get Class Info Inherited from cObject
Get Data Inherited from cObject
Get Data Size Inherited from cObject
Set Data Inherited from cObject
cEntity—an abstract "thing" with address properties
An entity is anything that physically or virtually exists in a number of address spaces. An entity object is defined as something with a name and at least one default address (store-and-forward), but probably with two default addresses (store-and-forward and realtime). NOTE: This class should NEVER be instanciated as an object by itself, but is used to iterate over a group of like items.
SuperClass cRow (Table suite)
Default Descriptor
Type
typeEntity
Properties
pBestType
Description: The descriptor type that can contain the most information from objects of this object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pClass
Description: The four-character class ID for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pDefaultType
Description: The default descriptor type for the object class
Object Class ID: cType
Inherited? Yes, from cObject
Modifiable or
Non-modifiable? Non-modifiable
pUniqueID
Description: the unique ID for this entity
Object Class ID: cText
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Non-modifiable
pName
Description: the name of this entity
Object Class ID: cIntlText
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Non-modifiable
pProtection
Description: see the Table Suite
Object Class ID: cEnumeration
Inherited? Yes, from cRow
Modifiable or
Non-modifiable? Non-modifiable
pEntityType
Description: the enumerated type of entity
Object Class ID: cEnumeration
Inherited? No
Modifiable or
Non-modifiable? Non-modifiable
pPrimaryRealTimeAddress
Description: the primary real time address (ie phone #)
Object Class ID: cAddress
Inherited? No
Modifiable or
Non-modifiable? Modifiable
pPrimaryMailAddress
Description: the primary mail address of this entity
Object Class ID: cAddress
Inherited? No
Modifiable or
Non-modifiable? Modifiable
Element Classes
cAddress
Description: the various addresses for this person
Descriptor types defined in the Collaborative Information suite
The descriptor types defined in the Collaborative Information suite are described in the following sections. Table 4 lists these descriptor types.
n Table 4 Descriptor types defined in the Collaborative Information suite
Descriptor type Description
typePhoneNumber A phone number descriptor
typeAttribute an attribute descriptor
typeAddress an address descriptor
typeUserField an address descriptor
typePostalAddress a postal address descriptor
typePhoneAddress A phone address
typeMailAddress a mail address descriptor
typeEntity an entity descriptor
typePerson a person descriptor
typeEquipment an equipment descriptor
typeLocation a location descriptor
typePhoneNumber—a phone number descriptor
A typePhoneNumber descriptor record contains the data for a cPhoneNumber object. It includes all the information necessary to recreate the original cPhoneNumber object.
Description To create a typePhoneNumber descriptor record, you coerce an AE record containing the following fields into the equivalent typePhoneNumber descriptor record:
Keyword Descriptor type Description
keyAECountryCode typeIntlText the phone number country code
keyAEDialPlanRules typeAEList the phone number's list of dial plan rules
keyAEExtension typeIntlText the phone number extension
keyAESubscriberNumber typeIntlText the phone number subscriber number
keyAESubaddress typeIntlText the phone number sub-address
keyAETrunkCode typeIntlText the phone number trunk code (typically the area code)
Normally kAECountryCode contains the appropriate PSTN country code. If the phone number specified is not on the PSTN, kAECountryCode identifies the network the party is on. (The Telephony Apple event server must be capable of supporting this.)
Note that the Apple Event Manager can coerce any AE record into any other descriptor type. A special coercion handler is not required.
All Telephony Apple event servers must support coercion of typePhoneNumber into typeIntlText and the reverse. When mapping the data into IntlText the following format is to be used:
[DPR1,DPR2,…DPRn]+CC(TC)SN*SAxEXT
where CC= CountryCode {0-9}
TC= TrunkCode (typically the area code) {0-9}
SN=Subscriber Number {0-9,A-Z}
SA=Subaddress {0-9}
EXT=Extension {0-9}
DPR=Dial Plan Rules {all displayable charcaters}
' ', '-' & '.' are ignored except in DPR.
Fields are parsed as empty on the following basis:
CC= No "+"
TC= No "("
SN= No characters before "x"
SA= No "*"
EXT=No "x"
DPR=No "["
The reverse mapping involves accepting a string in a similar format.
Data Size Variable
typeAttribute—an attribute descriptor
A typeUserField descriptor record contains information about the properties and elements of the cUserField object class.
Description To create a typeAddress descriptor record, you coerce an Æ record containing the following fields into the equivalent typeUserField descriptor record:
Keyword Descriptor type Description
keyAEValue typeIntlText the data for this attribute
keyAEID typeLongInteger the ID of this attribute
keyAEName typeIntlText the name of this attribute
keyAETag typeType the type of this attribute
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
typeAddress—an abstract address descriptor
A typeAddress descriptor record contains information about the properties and elements of the cAddress object class.
Description To create a typeAddress descriptor record, you coerce an Æ record containing the following fields into the equivalent typeAddress descriptor record:
Keyword Descriptor type Description
keyAEAdressName typeIntlText the address name
keyAEAdressType typeIntlText the address type
keyAEAdresseeName typeIntlText the addressee name
keyAEAddresseeType typeIntlText the addressee type
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
Notes A client would probably want to find out the address type of the returned descriptor and them coerce it into the appropriate type, instead of into this type.
typeMailAddress—a mail address descriptor
A typeMailAddress descriptor record contains the data for a cMailAddress object. It includes all the information necessary to recreate the original cMailAddress object.
Description To create a typeMailAddress descriptor record, you coerce an AE record containing the following fields into the equivalent typeMailAddress descriptor record:
Keyword Descriptor type Description
keyAEAdressName typeIntlText the address name
keyAEAdressType typeIntlText the address type
keyAEAdresseeName typeIntlText the addressee name
keyAEAddresseeType typeIntlText the addressee type
keyAEAddress typeIntlText the actual address in the specified address space
keyAEDirectory typeIntlText the address space
keyAEDirectoryType typeIntlText the address space type
keyAEDirectoryID typeIntlText the address space discriminator
All Mail Apple event servers must support coercion of typeMailAddress into typeIntlText and the reverse. When mapping the data into IntlText the format described below is to be used.
The following characters are used as tokens:
".", "<", ">", "@" and "\"
The latter is the escape character for quoting the other tokens in fields where they are reserved as indicated below.
The component fields of the string address are listed below. Every field except the Addressee Name and the Directory Name field can be optional depending on the circumstances.
NAM = Addressee Name (".", "<" and "@" must be quoted with "\")
TYP = Addressee Type ('User' if not specified, "<" must be quoted with "\")
EXT = Address Type (Default = 'entn')
EXV = Address Value (">" must be quoted with "\")
DIR = Directory or Address Space Name ("." and "<" must be quoted with "\")
This may be expressed as a Path{Subspace of Address Space}
so it would be (NODENAME.)*DIR where "(_)*" means "zero or more of _"
DIT = Directory or Address Space Type ('adap' used if ambiguous & unspecified)
DID = Directory or Address Space Discriminator (Required if DIT is specified)
The TYP, EXT, and DIT fields are all four bytes which may be any displayable ASCII characters.
The string representation for addresses is then as follows:
NAM.TYP<EXT.EXV>@DIR<DIT.DID>
Examples:
Michael Bayer@Evangelism.MSAD.APPLE
M\. Bayer@Evangelism.MSAD.APPLE
Michael Bayer.User@Evangelism.MSAD.APPLE
Evangelists.Group@Evangelism.MSAD.APPLE
NASDAQ.StockAgent@CORP.APPLE
Michael Bayer<entn.123.456>@Evangelism.MSAD.APPLE<adap,001>
Michael Bayer<alan.MBQuadra.Evangelism>@AppleR&DNetwork
Michael Bayer<fax .+1(408)974-1211>@FAX
Michael Bayer<smtp.bayer1@applelink.apple.com>@INTERNET<smtp,0>
Michael Bayer<alnk.BAYER1>@AppleLink
NOTE: These string representations of an address are always represented using an appropriate script code. The tokens listed above (".", "<", ">", "@" and "\") are represented in the script specified by the IntlText. The Addressee Type, Extension Type and the Directory Type are each 4 Bytes and are always interpreted using Roman ASCII.
typePostalAddress—a postal mail address
A typePostalAddress descriptor record contains information about the properties and elements of the cPostalAddress object class.
Description To create a typePostalAddress descriptor record, you coerce an Æ record containing the following fields into the equivalent typePostalAddress descriptor record:
Keyword Descriptor type Description
keyAEAdressName typeIntlText the address name
keyAEAdressType typeIntlText the address type
keyAEAdresseeName typeIntlText the addressee name
keyAEAddresseeType typeIntlText the addressee type
keyRoomNum typeIntlText the room number
keyBuildingNum typeIntlText the building number
keyStreet typeIntlText the street name
keyCity typeIntlText the city name
keyStateProvince typeIntlText the state or province name
keyCountry typeIntlText the country name
keyPostalCode typeIntlText the zip code or equivalent
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
typePhoneAddress—a phone address descriptor
A typePhoneAddress descriptor record contains the data for both a cPhoneAddress and a cParty object. It includes all the information necessary to recreate the original cPhoneAddress or cParty object.
Description To create a typeParty descriptor record, you coerce an AE record containing the following fields into the equivalent typeParty descriptor record:
Keyword Descriptor type Description
keyAEAddresseeType typeIntlText the addressee type
keyAEAddresseeNametypeIntlText the name of the addressee
keyAEAddressNametypeIntlText the name of the address
keyAEAddressTypetypeIntlText the type of this address
keyPhoneNumber typePhoneNumber the phone number
Data Size Variable
typePackedDSSpec—a mail address descriptor
A typePackedDSSpec descriptor record contains the data for a cMailAddress object represented as an AOCE PackedDSSpec data structure as defined in the AOCE Utilities chapter of Inside Macintosh. It includes all the information necessary to recreate the original cMailAddress object.
All Mail Apple event servers must support coercion of typePackedDSSpec into typeIntlText and typeMailAddress and the reverse. When mapping the data into typeIntlText the same format described for coercion of typeMailAddress is to be used.
typeEntity—an abstract entity
A typeEntity descriptor record contains information about the properties and elements of the cEntity object class.
Description To create a typeEntity descriptor record, you coerce an Æ record containing the following fields into the equivalent typeEntity descriptor record:
Keyword Descriptor type Description
keyAEID typeText the unique ID for this entity
keyAEName typeText the name of this entity
keyAEEntityType typeEnum contains the enumerated type
keyAEStoreForward typeIntlText the primary realtime address of this entity
keyAEMailAddress typeIntlText the primary mail address of this entity
keyFieldList typeAEList A list of typeUserField descriptors.
keyAddressList typeAEList A list of typeAddress descriptors.
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
typePerson—a person descriptor
A typePerson descriptor record contains information about the properties and elements of the cPerson object class.
Description To create a typePerson descriptor record, you coerce an Æ record containing the following fields into the equivalent typePerson descriptor record:
Keyword Descriptor type Description
keyAEID typeText the unique ID for this entity
keyAEName typeText the name of this entity
keyAEEntityType typeEnum contains the enumerated type
keyAEStoreForward typeIntlText the primary realtime address of this entity
keyAEMailAddress typeIntlText the primary mail address of this entity
keyFieldList typeAEList A list of typeUserField descriptors.
keyAddressList typeAEList A list of typeAddress descriptors.
keyIndex1Name typeIntlText the first name of this person
keyIndex2Name typeIntlText the last name of this person
keyIndex3Name typeIntlText the middle name of this person
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
typeEquipment—an equipment or resource descriptor
A typeEquipment descriptor record contains information about the properties and elements of the cEquipment object class.
Description To create a typeEquipment descriptor record, you coerce an Æ record containing the following fields into the equivalent typeEquipment descriptor record:
Keyword Descriptor type Description
keyAEID typeText the unique ID for this entity
keyAEName typeText the name of this entity
keyAEEntityType typeEnum contains the enumerated type
keyAEStoreForward typeIntlText the primary realtime address of this entity
keyAEMailAddress typeIntlText the primary mail address of this entity
keyFieldList typeAEList A list of typeUserField descriptors.
keyAddressList typeAEList A list of typeAddress descriptors.
keyManager typePerson Who manages this location
keyEquipmentType typeIntlText the type of equipment
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
typeLocation—a location descriptor
A typeEquipment descriptor record contains information about the properties and elements of the cLocation object class.
Description To create a typeEquipment descriptor record, you coerce an Æ record containing the following fields into the equivalent typeEquipment descriptor record:
Keyword Descriptor type Description
keyAEID typeText the unique ID for this entity
keyAEName typeText the name of this entity
keyAEEntityType typeEnum contains the enumerated type
keyAEStoreForward typeIntlText the primary realtime address of this entity
keyAEMailAddress typeIntlText the primary mail address of this entity
keyFieldList typeAEList A list of typeUserField descriptors.
keyAddressList typeAEList A list of typeAddress descriptors.
keyManager typePerson Who manages this location
keyLocCapacity typeInteger the capacity of this location
Note that the Apple Event Manager can coerce any Æ record into any other descriptor type. A special coercion handler is not required.
Data Size Variable
Constants defined in the Collaborative Information suite
Table 7 lists the constants defined in the Collaborative Information suite.
n Table 7 Constants defined in the Collaborative Information suite